Risk analysis approach
During the execution of a risk analysis, it is recommended to make a distinction between analyses of the critical success factors on the one hand and the analysis of risks on the other hand. The analysis of critical success factors is relatively simple. The first critical success factor, top management support, can be arranged by measures like periodical explicit approval for next steps in the implementation, and the corresponding approval for budgets. The second critical success factor, the availability of an ERP champion who sponsors the ERP implementation, takes ownership for it and promotes it, can be realized by the appointment of a member of the top management team for this role. The third critical success factor, the continuous communication with all stakeholders, can be realized by the design and rigorous execution of a communication strategy for the ERP implementation. The strength of these individual measures can be increased by overarching measures that tie the sponsor, the other members of the top management team and other stakeholders to the success of the ERP objectives. Examples of such measures are integration of the ERP objectives into the organizational strategy and annual plans, and the creation of a link between ERP achievements and bonuses or other types of variable compensation.
The analysis of risks starts with the risk identification, the creation of a list of potential events that could negatively influence the attainment of the objectives of the ERP implementation. The list starts with the four aforementioned risks, and can then be extended with industry- and organization-specific risks. Good starting points of lists with risks associated with large project can be found in books on risk management, such as Kupras [1993] or Gevers & Hendrikxs [2001].
After the creation of a list with risks, the severity of each risk has to be determined for each of the preselected ERP systems that are taken into account in the ex ante evaluation, and corresponding control measures have to be designed. In below image, the risk management process is depicted graphically.
Firstly, probability and impact of the risk are determined in case no controls are implemented. Secondly, controls are designed that avoid, reduce or transfer the risk. Per measure, the costs are determined, as well as the reduced probability and impact of the risk when the control would be implemented. Finally, the control that minimizes the risk is selected for implementation. It is also possible to implement more than one control to mitigate a single risk; for readability reasons, this possibility has not been depicted in above image.
Like a functional it analysis, a risk analysis is best executed as a subproject of the ex ante evaluation of ERP. And like for the functional it analysis, the quality of the results is highly dependent on the composition of the project team. In the project team, knowledgeable risk managers, experienced project managers, and experts in the organizational processes are essential.
The specialists in risk management are required in the project team because they know the methods and techniques that are applied in risk analysis projects. If the company employs a risk manager then this person is an obvious candidate for participation in the risk analysis team. Other suitable candidates are internal, operational and IT auditors.
The experienced project managers bring the practical experience of risk identification and assessment to the team. When the organization has already completed ERP implementations, the project managers of previous projects can be very valuable for the risk analysis. When the company does not have employees with sufficient knowledge and experience, hiring an external consultant who has experience with managing ERP implementations for participation in the project team is worth considering.
The experts in organizational processes have an essential role in the assessment of risks and the design of appropriate controls. They have intimate knowledge of the organization and can make well-founded estimates of the impact of adverse circumstances.
Various tools and techniques are available for the support of risk analysis. Well-known techniques for risk identification are workshops and open-ended interviews. Project evaluation documents and audit reports can also be useful sources for risk identification. For risk assessment, numerous methods can be applied, such as scenario analysis, benchmarking, sensitivity analysis, or advanced statistical techniques such as value-at-risk or cash low-at-risk [COSO, 2004].
Tools that automate a risk analysis are hardly available. The functionality of software that is advertised as suitable for risk analysis is mostly meant for compliance projects and internal controls. For an ex ante evaluation of ERP this software is too cumbersome. Traditional software for voice automation, like a word processor or a spreadsheet is the best tools for risk analysis.
One final remark with respect to the outcomes of a risk analysis is in order. Above, a description is given for the execution of a well-structured risk analysis. It is certainly recommended to apply this structure and carry out a diligent risk analysis.
However, the outcomes of a risk analysis are never complete, because it is not possible to predict all circumstances that might endanger the realization of the objectives of the ERP implementation. Moreover, the outcomes of a risk analysis can never be exact and unambiguous, because both the probability that an adverse event will occur and its impact are estimates that are subjective. It is therefore recommended to avoid a false sense of accuracy by presenting very detailed and precise outcomes of a risk analysis without an indication that the outcomes are to a large extent based on assumptions and estimates.